What is Swarm Mode Orchestration?
Swarm is a simplified way to orchestrate groups of containerized applications into a service.
Swarm provides a simple, straightforward way to orchestrate containers, often used in situations where companies feel their needs are not suitably complex to warrant using Kubernetes. Thousands of organizations use Swarm, today, and Swarm is under active development by Mirantis.
Where do I get Swarm?
Enterprise Swarm is now offered as an alternative orchestration type with Mirantis Kubernetes Engine (MKE). Users can access the Mirantis Kubernetes Engine webUI to switch nodes to Swarm or ‘mixed’ (i.e., Kubernetes+Swarm) mode at will. Open source Docker Engines can also be combined in a swarm, using CLI commands.
What are Swarm services?
Swarm services are application components that work together to create a full application. This may include the application itself, any external components it needs such as databases, and network and storage definitions. We’ll say more about them under Swarm concepts.
Swarm vs Kubernetes
The long-running battle, of course, is between Swarm and Kubernetes. Each has its advantages, of course; Swarm gained a lot of traction to start because it is part of Docker itself, so developers don’t need to add anything else. It’s also simpler to deploy and use than Kubernetes. Kubernetes, however, has long-since surpassed Swarm in usage, and has its own environments and adherents.
That doesn’t however, mean there’s a clear answer as to which is “better”. There are many factors that determine which is better for you, such as existing environment, target environment, application complexity, and so on.
For example, Mirantis Secure Registry (formerly Docker Trusted Registry) runs as a Swarm (or Kubernetes) workload.
There are even utilities that translate Swarm “stacks” into Kubernetes definitions to enable you to move from one to the other. In fact, throughout this page you will see allusions to both, as we provide the Kubernetes “equivalent” for Swarm concepts for those who already understand K8s.
Swarm concepts
To understand which might be right for you, it’s important to understand the concepts that underpin Docker Swarm.
Swarm vs a Swarm
Swarm is the technology that enables a Docker-compatible container engine to orchestrate containers and other components. The collection of servers on which this collection of orchestrated “stuff” runs is referred to as “a Swarm.”
Swarm Services
In Kubernetes, we would consider a “service” to be a network entity that makes it possible to reach individual containers. In Swarm, however, a “service” means something completely different.
A Swarm service is the equivalent of a container and all of the information needed to instantiate and run it.
For example:
version: '3'
services:
main:
image: nickchase/rss-php-demo
environment:
- site=mirantis
networks:
- default
deploy:
replicas: 3
networks:
default:
external: false
There are two types of Swarm services. Replicated services are instantiated as many times as you’ve requested. If you ask for three of a replicated service, you get three. If you ask for 10, you get 10, and so on. Global services, on the other hand, are like Kubernetes DaemonSets, in that you have one instance running on each node.
Nodes
Nodes are the physical or virtual machines on which Swarm runs your workloads. Swarm has two types of nodes: manager nodes and worker nodes.
Manager nodes are just what they sound like; they are the nodes that coordinate everything that goes on within the cluster, from scheduling workloads (that is, running them on a particular machine) to monitoring the swarm so that any failed services can be restarted.
Worker nodes, on the other hand, are where these services actually run.
A single machine can serve as both a manager and worker node, in which case workloads can run on any server in the swarm.
Note that at the end of the day, these are still not just Swarm nodes, but container engines, so individual containers (that is, containers that are not part of Services) can run on any of these nodes.
Swarm Stack
A swarm stack is a collection of services that work together to form a complete application. It also includes other components those services need, such as databases or networks. For example:
version: '3'
services:
main:
image: nickchase/rss-php-demo
environment:
- DATABASE=db
networks:
- public
- default
deploy:
replicas: 3
db:
image: mysql
networks:
- default
networks:
default:
external: false
public:
external: true
Load balancing and Ingress
As an orchestration engine, Swarm decides where to put workloads, and then manages requests for those workloads. Swarm allows you to use multiple load balancing mechanisms, including Spread, which tries to keep the usage of each node as low as possible, and BinPack, which tries to use as few servers as possible to handle requests from within the cluster.
Internally, Swarm assigns each service its own DNS entry, and when it receives a request for that entry, it load balances requests between different nodes hosting that service.
Swarm at scale
Mirantis Kubernetes Engine (MKE), provides enterprise-level Swarm capabilities.
One of the advantages of working with Swarm is that developers can use the exact same artifacts — including the stack definition — in both their development and production environments. It's possible, therefore, to build development environments using (freely downloadable) Docker Engines networked in a Swarm, and use an enterprise-class orchestration platform like MKE, in Swarm mode, for production.
What, then, is Swarm?
To circle back to the beginning, Swarm is a simplified but powerful container orchestrator that enables you to build complex applications in a robust, scalable way.
Learn more about Swarm
Learn more about enterprise Swarm.
Learn more about the role of secure container runtime.
Learn more about the importance of a secure registry.